Ham Radio/Ham Radio CD-ROM (Emerald Software) (1995).ISO/misc/chknglue/chknglue.doc

Text File | 1987-05-18 | 39KB | 786 lines

                            Chunk 'n Glue V1.5

I.   Introduction

As you probably know, the packet radio channels have become extremely
crowded.  One of the contributing factors to this crowding is long file
transfers, usually via the linked BBS system.  Transfers of files larger
than about 10kb are usually impractical and always considered to be anti-
social behavior.  And if you are interested in sending ASCII-encoded binary
files using one of the popular protocols such as PAK, PAK/UNPAK, BTOA, BSQ,
etc., you know the problem is even more severe.  These files are HUGE.  So
what to do.  Well the obvious solution is to break the large files up into
little chunks for transmission and recombine them at the receiving end.
PAK/UNPAK supports small files, but its encoding scheme is fairly
inefficient resulting in much more transmission data than do the others.
And PAK/UNPAK cannot break up text files without encoding them thus
expanding their sizes. So again, what to do.

Well, a cry from the wilderness was heard, saying "Write a program.....
write a program....", so I did!  I am a firm believer in the UNIX concept
which is one of a "toolbox" of programs and utilities.  Each tool is
designed to do only 1 thing but do it well.

So the obvious solution was to write a program that would take an ascii
textfile, split it up into little chunks and wrap the chunks in sufficient
protection so as to have a reasonable assurance that they will survive the
trip over the packet channels.  Thus CHUNK which chunks 'em up and GLUE
which glues them back together again.

II.  A usage example.

Suppose I had a group of related files that I wanted to send to a friend in
Florida via the packet network.  For example, lets take this package,
Chunk'n'Glue.  The files would be CHUNK.EXE, CHUNK.C, GLUE.EXE, GLUE.C,
CHUNK, GLUE, and CHKNGLUE.DOC.  The most efficient way would be to combine
them into an ARChive file using the popular public domain program ARC.EXE.
The command line would be:

ARC A CHUNK *.*<CR>

which would result in a file CHUNK.ARC being created and all the above
files being included.  ARC does a very sophisticated data compression
algorithm on the incoming files, so the arc file will be much smaller than
the total size of all the input files.

So now we have an ARC file which is still pure binary and thus incompatible
with the bbs system.  Well there are several programs available such as
PAK, BSQ, and BTOA, but all but BTOA attempt their own compression as they
encode.  Generally speaking, it's a no-no to recompress data that's already
been compressed.  The resulting file tends to be HUGE.  So, since we're
already compressed in the ARC file, BTOA is the weapon of choice.  The
command line would be:

BTOA CHUNK.ARC CHUNK.BTA<CR>

This will produce CHUNK.BTA which will be about 20% larger than CHUNK.ARC.
CHUNK.BTA is consists entirely of printable ASCII characters and so is
compatible with packet bbs's.  Only one problem.  When I encoded this file,
the BTA file was over 44k long!  Sending something like that is clearly
anti-social!

"So wiseguy", you might ask, "just what IS social?"  Good question.
Several considerations enter into the discussion.  First is the "good
neighbor" philosophy.  That is, since a packet channel can only really
support one user at a time if he is sending files, one should not hog the
channel.  Everyone has his own opinion about hogging, but in general, I try
to limit my occupancy of the channel to no more than about 10 minutes at a
time.  Another very important consideration is the capability of the BBSs
that will be handling the files.  If your local bbs is a XEROX-based
system, he'll probably have 50-75k of free storage for "mail" files.  A PC
system running off floppies is not much better off.  So you really should
not fill the whole system up with your file transfer.

You obviously have to look at the transmission medium when making your
decision.  If you are sending to an adjacent bbs or a friend one digi hop
away, then much larger files are tolerable than if you are going through 4
digis or out on HF.  Similarly, at 3:00am in the morning, you can send
larger files than at 7:00pm!

All of these arguments point to sending via a bunch of small files but
there is a consideration that argues to the contrary.  A whole bunch of
files, say >10, files are likely to get lost or at least take forever
getting to your destination.  So a compromise is in order.

What I've found to work well is to send files in about 10k chunks if you
are going over a solid 1 hop VHF link.  For HF or poor links, no more than
5K is indicated.

So for our example, lets assume we've got a good solid VHF path so we can
use 10k chunks.  The objective therefore is to break this 44k .BTA file up
into 10k chunks for transmission and then be able to put them back together
into the original file on the receiving end.  Well you could use your
favorite editor but this is generally a poor solution.  First, editors
generally don't like really big files.  Second, they tend to put funny
things like ^z's in the files.  Third, there is no way of knowing if a
portion of a chunk has been lost somehow.  Then, of course, on the
receiving end, you have to make sure you put the chunks back together in
the right order.

Here's where Chunk'N'Glue come in.  Chunk simply breaks up the input file
into small chunks and then surround each chunk with "tokens" or markers
that show exactly where the chunk begins and ends.  You can tell Chunk how
big to make each chunk, but if you don't, it defaults to 5k.  Convenient,
eh?  In this example, we'll use a chunksize of 10k.  So to chunk the
CHUNK.ARC file, you would simply type:

CHUNK CHUNK.BTA -s10000<CR>

Chunk would then process the .BTA file into little chunks, in this case 5,
and tell you what it did.  Each chunk file has the name:

CHUNK.CHx  Where x is a sequential letter starting with A.

So in this case, the files CHUNK.CHA, CHUNK.CHB, CHUNK.CHC, CHUNK.CHD, &
CHUNK.CHE were created.

Now you can send these files, one at a time to your friend via packet.
When he gets them, he simply types:

GLUE CHUNK<CR>

Glue first checks to see if all the chunk files are there, and if so
processes them back into the original CHUNK.BTA file. (This assumes your
friend somehow already had GLUE, hi!).  Glue is smart enough to ignore BBS
header lines or prompts that may have become embedded in the chunk files so
he doesn't have to worry about editing this stuff out.  Just plug'n'play!

He would then convert it back into an ARC file by typing:

ATOB CHUNK.BTA<CR>

and extract the individual files by typing:

ARC E CHUNK<CR>

So there you have it. Simple and efficient.  You can automate this
procedure with simple batch files.

Now lets look back above for a minute.  Suppose you were going to transmit
over a poor path or on HF and thus wanted smaller chunk files, say 2.5k.
The Chunk command line becomes:

CHUNK CHUNK.BTA -S2500   or
CHUNK -S2500 CHUNK.BTA

The "-s" or "size" option tells Chunk to make 2.5k files instead of it's
default of 5k.  There is a somewhat arbitrary upper limit of 32k.  This is
primarily for my convenience in programming but it should not be a problem.
After all, it's not nice to send 32k files on packet!  If you specify a
number larger than 32k, Chunk will assume you made an error in typing and
use the default of 5k byte chunks.

Chunk has an optimizer built in which will eliminate so-called straggler
files.  Stragglers contain only a few bytes and occur when the original
file is just a tiny bit larger than an integral number of chunks.  Using a
chunksize of 5k for example, a file that is 25400 bytes long would create 6
chunks, the last of which would contain only 400 bytes.  When Chunk sees
this situation, it adjusts the chunksize to accommodate the bytes in one
less chunkfile.  So in this case, Chunk would make 5 chunkfiles, each about
5,080 bytes long.  Again, a somewhat arbitrary limit of 500 bytes has been
used as the cutoff to identify a straggler.  This feature will really cut
down the traffic on a packet channel because of the overhead involved in
sending a message.

III.   OPTIONS

     CHUNK options

In the example above, the use of Chunk and Glue was simple and
straightforward.  There are several options that change the performance of
both Chunk and Glue.  You've already seen one, the -s option on Chunk.
We'll look at Chunk first.  The complete command line for Chunk is:

CHUNK INFILE [-SXXXX] [-B] [-Z] [-M]

The items in the square brackets are optional.  It is important to note
that the options can be specified in any order, and before or after the
INFILE name.  Thus you could type:

CHUNK -S4000 INFILE -B

Lets look at each option in sequence.

     -S Option

You are already familiar with the -s option.  This specifies a chunkfile
size other than the default of 5k.  This specification can be up to 32,767
bytes.  If you specify a chunkfile larger than 32,767, Chunk will assume
you made a typing error and use the default of 5k.

     -B & -Z Option

The -b and -z options do the same thing; they are interchangeable.
Normally, as Chunk processes a file, it looks out for control-z characters
in the input file, and if it finds any, it ZAPS them to spaces.  Why?
Well, embedded control-z's royally screw up packet bbs systems.  When the
bbs sees a control-z, it simply thinks that the end of message has been
reached and stops accepting any more data.  Of course, anything following
the first control-z is lost, including the footer for CHUNK.

BUT, there are times you may not want to Zap Zee's.  If you are chunking a
binary file for transmission either in the transparent mode on packet or
via phone modem, killing Zee's is not nice.  So an option to turn this
killing mode off is included.  The -b and -z tell Chunk NOT to ZAP any
control-Z characters it finds in the input file as it processes it.  You
can think of this as either being a (Z)apping Zee's or a (B)inary mode.

The Zee-Zapping mode also enables one other feature.  This feature insures
that carriage return-line feed pairs don't get split up.  DOS and CP/M are
somewhat unique in that lines of text are ended with the 2 character
sequence, <CR>-<LF>.  Both characters are necessary and in this order.
Other systems, such as Unix use only a "newline" character which is also
called "linefeed", same as above.  The difference is that in Unix, the
printer driver takes care of making sure the printer carriage is returned
after each line as well as feeding the paper to the new line.  For DOS and
CP/M, we have to explicitly instruct the printer to return the printhead


with a <CR> and then feed a line with the <LF>.  Even though <CR> and <LF>
are two separate bytes, with few exceptions, they are always mated at the
end of each line of text.

Problems start to arise when we start chunking files.  If an odd chunksize
is specified with a file that has predominately even numbers of characters
in each line, it can occur that the chunk can end on a <CR> character and
its companion <LF> will end up as the first byte of the next chunkfile.

At this point, we don't have a problem.  Glue assumes that the chunks are
made up of arbitrary data and so will mate the errant <CR> and <LF>.  The
real problem occurs when we load the chunkfiles into a packet system for
transmission.  The BBS software looks for errant <CR>'s and <LF>'s and when
it finds one, inserts its mate.  So in the first chunkfile, a <LF> would be
added after the <CR> and in the second chunkfile, a <CR> will be added
before the <LF>.  Or, stated another way, the BBS has corrupted the
chunkfiles.  GLUE will notice the extra 2 bytes added and complain loudly.
And if the original chunked file was encoded binary from lets say, BTOA,
then these added bytes will corrupt the file when it is un-BTA'd.

So if Chunk is in the Zee-Zapping mode, it also looks for a <CR>-<LF>
sequence that is going to be split.  If it finds this occurrence, it goes
ahead and reads an additional byte from the original file and puts it in
the chunkfile.  (Sorta think of it as a marriage counselor for data!)  It
adjusts the bytecount in the chunkfile header accordingly.  Chunk also
looks at this extra byte, and if it is not a <LF> character, Chunk
complains that it has found a <CR> without a mating <LF> in the input file.
Whether or not this is a problem will have to be determined by you.  One
thing is for sure though, the chunkfile with the unmated <CR> WILL be
corrupted by the packet BBS system.

     -M Option

The -M option is the Memo option.  This option activates a small line
editor within Chunk which lets you add a memo or note to the beginning of
the first chunkfile.  Glue will display this memo on the screen while it is
putting the chunkfiles back together again.  This is a very handy feature
that will allow you to identify the contents of ASCII-Encoded chunkfile to
the recipient or place instructions in the chunkfile pertaining to the
contents.  When you have entered the Memo, type a ^Z to end it.


     Glue Options

Glue currently has 2 command line options.  You can specify an optional
name to be used for the output file and you can specify a queried ignore
option for errors.  The command line would be:

GLUE CHUNKFIL [OUTFILE] [-i]

Chunk stores the original file's name in the header of each chunkfile and
this name is normally used by Glue for its output filename.  If you specify
an output file name however, that name will override the name in the
chunkfile header.  So if you type the command:

GLUE CHKNGLUE GLUE.DOC

Glue would combine CHKNGLUE.CHA, CHKNGLUE.CHB, etc into one file, but
instead of using the name in the header line, it would call the output file
GLUE.DOC.

     -I Option

If you specify the -i option, telling GLUE to selectively ignore certain
error conditions, the program will notify you of any errors it encounters
and give you the option of ignoring them.  This is especially useful when a
chunkfile set has been corrupted, perhaps by a "*** CONNECT REQUEST" from
the tnc or from the <CR>-<LF> problem mentioned above.  If the original
file was plaintext, often times the corruption can be ignored or can be
more easily fixed with an editor after Glue is finished processing.  In
these cases, GLUE will generate an error message and then ask you whether
to quit or ignore the error.  If you choose to ignore the error, GLUE will
do its best to finish processing the chunkfiles and then provide you with a
more detailed error analysis regarding the error condition.  If BTOA or PAK
chunkfiles are being processed, obvious errors such as the *** Connect
Request messages can also be fixed manually, but care must be taken to
eliminate all extra <CR>-<LF> sequences also.  The -i option is NOT
recommended for binary files.


IV.   Other Features

A new feature starting with V1.3 is the so called "straggler file"
elimination algorithm.  A straggler file is one that contains only a few
bytes of data.  For example, suppose you had a file to transmit that is
25,100 bytes long.  Before now, Chunk would have made 6 chunkfiles, 5 of
which would contain 5000 bytes of data and the last which would contain
only 100 bytes - the straggler!  Since there is a large overhead involved
in any packet message or file transfer, I decided to get rid of the
straggler.  What Chunk does is look at the straggler and if it's going to
be less than 500 bytes, the sizes of the other chunkfiles are enlarged
enough to contain the straggler.  Thus, Chunk would now make only 5
chunkfiles and each would contain about 5020 bytes.


V. The CHUNK file format.

If you look at the first chunk file, CHUNK.CHA, you will see something like
this:

This file CHUNKed by the WD4OQC CHUNK'r
~~~ FcHuNk WD4OQC Vers 1.5 File A of E, chunk.bta 10000 47325
xbtoa Begin chunk.arc
)@/]$<DH0ez!!!!g!!!".%SN8"?=Ns8!":L"\9K5fNK+2M5X7Z_B$M5),ZO+qLi<ck3c<LW/>toZ!K

more data...




more data... (10k worth)...

6j743*@pD;@j#qciG\L!IM=?n1Xk5!,+=d%uF,jMdQuEE",F$#Z]dn=HE\i0FUk["Z%81*ZtVa!$5?
Q!15SJ%H%q7U(@:n!Eu]2EqX??Fb-"#%j[N\XM=q][LYK^!-E/j4O=/"O
~~~ EnDfChUnK Vers 1.5

A bunch of gobbledygook!  Lets look more closely.  The first line is a brag
line that essentially does nothing except positively identify to humans the
source and type of the file.  The second line is what we call a "token" or
header line.  It serves 2 purposes.  One is to positively mark where the
data starts.  Second, it contains vital data needed by Glue, such as the
original file's name and how many files are in this set.  Each bit of text
separated by a space is called a field.  Lets look at them more closely.

~~~            The triple tilde string.  This is a unique marker used by
               Glue to figure out where the header begins. Since the tilde
               is a rare character in the English language, most likely its
               occurrence in a file will mark a header.

FcHuNk         This field identifies the datafile as coming from chunk.  It
               is highly desirable that a header line contain highly unique
               data in order to simplify recognition.  Thus the alternate
               upper and lower case letters.

WD4OQC         My call, to identify the author in the event someone cannot
               find out what's making those funny files and wants to look
               me up in the callbook.

Vers 1.5       Current version number.  Generally expect files generated
               with pre- version 1.3 to be incompatible with newer ones,
               since the major reason for upgrades is to fix deficiencies
               in the program.  Look to the release notes, CHANGES.CNG, for
               details.  Minor changes to old chunk files can be made with
               an editor.  Major changes will probably be supplied with a
               conversion program.

File A of E,   This field tells GLUE first, which file in sequence it is
               dealing with and second, how many total files there are.
               The numbering sequence is A through Z for a total of 25
               possible files.  Thus with a limit of 25 chunkfiles at a
               maximum size of 32k each, you can chunk files over 800k!

chunk.bta      This is the name of the original file that was chunked.
               This file is recreated by GLUE.

10000          This is the exact size in bytes of the data area in the
               chunk file, ie, the data between the header token and the
               footer token.  This count is EXACT and excludes the CR-LF
               sequence CHUNK places after the header line and before the
               footer line.  These are, of course, stripped out by GLUE.





47325          This is the exact file size of the original file in bytes.
               This number is used as an extra error check to insure the
               GLUE'd file is the same as the one that was CHUNK'd.

<CR><LF>       The CR-LF sequence ends the header line.  The NEXT byte is
               the first byte of the data area.

The next line, "xbtoa Begin chunk.arc" also looks suspiciously like a
header and it is!  But it's the header of the chunked file itself, in BTA
format.  It's also the first data in the chunk file.

Looking at the end of the chunkfile, we see the line:

     ~~~ EnDfChUnK Vers 1.5

This is the footer of the chunkfile that tells GLUE exactly where to stop
and to ignore any characters that may follow it.  Characters such as the
BBS prompt following a download from the BBS.

VI.  ERROR MESSAGES

Chunk and Glue provide a wide variety of error messages to inform you of
what is happening or what happened to cause failure.  Most are self-
explanatory and all are listed below.

CHUNK Error Messages

-  *** WARNING - Bad chunksize - Using 5,000 bytes
-  *** WARNING - Bad Option on command line - x - Ignored.
-  *** WARNING - Specified chunksize > 32767 bytes - using 5,000 bytes.
-  *** WARNING - A <CR> without a <LF> was found at the end of chunk X.

0. ---         No errors encountered, OK.
1. *** ERROR - File name must be specified on command line
2. *** ERROR - Not enough ram to proceed. - Exiting ...
3. *** ERROR - Filename xxx not found",infilename - Exiting ...
4. *** ERROR - Can't open xxx - Disk full?? - Exiting ...
5. *** ERROR - Error Writing file xxx - Disk full??? - Exiting ...
6. *** ERROR - Chunksize selected will result in too many files - Increase");
               chunksize and try again - Exiting ...
7. *** ERROR - *deleted* v1.3 - not used in this version.
8. *** ERROR - Written Bytes not equal to read bytes.

The number out to the side of each error is the EXIT CODE Chunk returns to
DOS when it exits.  You can make use of these error codes in DOS batch
files through the ERRORLEVEL statement to do different things according to
what went wrong.








GLUE Error Messages

1. *** ERROR - File name must be specified on command line");
2. *** ERROR - Not enough ram to proceed. - Exiting ...
3. *** ERROR - First chunkfile, xx not found - Exiting ...
3. *** ERROR - Chunkfile xx not found - Exiting ...
4. *** ERROR - Can't open output file xxx - Disk full???
5. *** ERROR - Writing file xxx - Disk full??? - exiting ...
6. *** ERROR - Opening header not found - Maybe not a CHUNK file? - Exiting ...
7. *** ERROR - BAD option - exiting ...
8. *** ERROR - Invalid Beginning token found - Exiting ...
9. *** ERROR - Chunkfile corrupted - File is too short
10.*** ERROR - Chunkfile corrupted - File is too long.
11.*** ERROR - Actual file size different than header file size.


VII.   WHAT CAN GO WRONG

The three most common problems will be:

1.   Chunkfile too long corruption
2.   Footer missing
3.   Extraneous ^z's.

1.   Chunkfile too long corruption - The most common cause of this error is
     a connect request coming into your station while you are downloading a
     file.  It will consist of the line "*** connect request: wd4xxx".
     Since there is no way to suppress this effect, you should occasionally
     expect it, especially if, for some reason, yours is a popular station
     to connect to. (A good store of dirty jokes on disk, fer'instance.)
     The easiest solution is to use your editor to find the offending
     string and delete it.  CAUTION: you MUST be exact in your deletions
     including <CR><LF> sequences.  On PAK'd and BTOA'd files this is easy,
     since each line will be exactly the same length.  In general, expect
     to have to delete the string and one <CR><LF> sequence.

2.   Footer Missing - This will most likely happen in the last chunkfile if
     the original file had a ^z EOF marker at its end.  CHUNK processes a
     file into chunkfiles EXACTLY - It does no filtering of any kind.  Thus
     the ^Z gets passed through like any other data.  The ^z WILL terminate
     the file when it is uploaded to the BBS or if an editor like WordStar,
     which respond to ^z, is used.  The solution is generally simple.
     Generally no data is actually lost so the footer should be added
     manually with an editor.  Since the ^z was represented in the byte
     count stored in the header, you will have to put a space at the end of
     the last line before the footer to make up for this byte.  Use the
     Zee-Zapping Chunk option to insure this is not a problem.








3.   Extraneous ^z's - Similar to the above problem except that if a ^z
     gets embedded in the data at other than the end and the chunkfiles are
     handled by BBS, all following data in that file will be lost.  Some
     editors, such as PC-WRITE, will allow you to put a ^Z anywhere in a
     datafile by keying ALT-26.  PC-WRITE and Chunk ignore the ^Z but the
     BBS does not!!!!  The only real solution is to have the sender rechunk
     the original file and re-send the offended one AND all subsequent
     ones.  Of course, the Zee-Zapping Chunk option will eliminate this
     problem.

VIII.  OTHER USES

Though CHUNK was originally written for use on Amateur Packet radio, it has
many other uses.  Some are outlined below.

     1.   Binary files

CHUNK handles binary data with the same ease as text - at least in the DOS
environment.  (This may not be strictly true on such systems as CP/M which
use a special byte to signal EOF.)  So it can be used to chunk binary files
as well as text.  Why would you want to do this?

Well, consider one of my experiences.  I've collected a few games for the
PC over the years.  I've kept them in a single ARC file on my hard disk.
This ARC has grown until it now approaches 800k!  Since it was taking up a
large amount of disk space, I wanted to off-load it to floppies.  But it's
too big for one floppy.  CHUNK to the rescue.  I simply chunked the ARC
into 32k chunks and copied them to floppies.  This is a very efficient
method, as it will waste at most, <32k of floppy space.  When I want to
recover the ARC file, I simply copy all the chunk files over to the hard
disk and let GLUE put 'em back together again.

     2.   Phone Modem Operations

Another use is in phone modem operation.  Say I wanted to transfer that
same game ARC file to a friend of mine.  I COULD send the file in one piece
using XMODEM or whatever.  This is inadvisable for several reasons.  First,
I really would not want my phone tied up for hours.  Second, XMODEM can be
crashed by noise or poor line conditions.  If it crashed 700k into the
transfer, it'd be something to cry about!  It is much better to CHUNK the
file and send the pieces a group at a time.  If you wanted to limit
yourself to perhaps an hour per night, it would take several nights but you
would eventually get them all sent.  And if the transfer crashes, at most
one file would have to be resent.

Yet a third use is on CompuServ.  Lets suppose you've just completed an
expository essay on why programmers that release public domain software
without source are such hairballs.  This could easily run 30k or more.
Problem is that the message section of most services such as CompuServ have
a limit of perhaps 2k on messages.  You realize that if you upload your
work of art as a file, it will probably be ignored.  CHUNK to the rescue.
Simply CHUNK your text file into, say 1800 byte chunks and upload them



sequentially.  Title your messages appropriately, say "Hairballs, 1 of 20".
From the reader's point of view, he can read each message sequentially,
ignoring the CHUNK headers or he can capture them all and GLUE them back
together for reading or printing.  NEET, huh?



IX   PATCHING CHUNK OPTIONS

Chunk is shipped set up so that the Zee-Zapping option defaults ON and the
Memo option defaults OFF.  So the command line option -Z turns Zee-Zapping
OFF and the -M option turns the memo field ON.  This should be the way most
people use the program under normal conditions for Packet radio.  Most
chunkfiles will not need a memo field, so this is off.  However, if these 2
defaults are not convenient, Chunk has provisions for patching them to the
opposite state.

The simplest way to change default states is to change the flag in the C
source code file and re-compile.  However, in the event you don't have a
professional C compiler, you can use a sector editor such as the Norton
Utilities or the public domain PATCH program (included) to effect the
change.

At this point I must warn you that this type patching requires that you be
familiar with patching in general and also familiar with your patching
program.  In particular, if you use the DOS DEBUG program, use extreme
caution.  DEBUG can alter any arbitrary sector on your disk and will do so
without warning or confirmation.

The major problem in patching C programs at the executable file level is
finding the right place to patch.  The compiler and linker can put the
patch area at any arbitrary place in the .EXE file.  The Microsoft C v4.0
compiler puts all initialized variables near the end of the .EXE file.  To
facilitate finding the patch area, I've defined a couple of patch FLAG
labels that will show up when you peruse the binary data.  These 2 flags
are ZAPFLAG and MEMOFLAG.  These 2 words will appear in the binary data
immediately BEFORE the patch bytes.  And remember that the string will be
terminated with a 0 so the actual patch area starts AFTER the 0.  Both
flags are stored as 2 byte integers with 00 00 being false and 01 00 being
true.  At least in the 8086 world, the bytes are stored LSB first, so the
FIRST byte is the one to change.  Simply change the 00 to a 01 or a 01 to a
00.

I cannot give you a more detailed instruction on patching because there are
a myriad of patching tools available and all are different.  Since CHUNK
will tell you what it is doing, a simple test will verify the correctness
of the patching.

An important note.  The -Z and -M options on the command line actual TOGGLE
the state of the option.  For example, the Zee-Zapping mode is shipped
defaulting ON so a -Z will toggle it OFF.  If you patch CHUNK so that Zee-
Zapping defaults OFF, the -Z option will toggle it OFF.  Same for the Memo
option.  This is very important to understand.


If you type CHUNK on the command line without a filename argument, CHUNK
will give you a short help screen and exit.  This help screen will indicate
the action of all options and will reflect any patching.  So if you get
lost or forget what the defaults are, simply type CHUNK and look at the
help message.


X  AVAILABILITY, SOURCE, ETC.

CHUNK'N'GLUE is available directly from me at:

John G. De Armond WD4OQC
po box 3657
Cleveland, TN 37311

It is shipped complete with C source code, DOC files, a bug list, and
Microsoft MAKE files.If you'd like a copy, send me 3 things:

1.   An IBM DSDD formatted disk - 360k 5".
2.   A reusable disk mailer with return address labels
3.   Enuf postage to cover it's return.

All 3 must be included.  Since I'm giving this program set away, I WILL NOT
go to any extra trouble to fix up your FUBARS.  If all three items are not
included, I'll simply add what you DID send to my user-donated collection
and be done with it.

If, when you send me a disk, you'll send a little note telling me you are
interested, I'll include a copy of PAK, BTOA, BSQ and so on.  These tools
should really be in any professional packeteer's toolkit!

I don't like the concept of BEGware (ShareWare to some) for such simple
utilities, but if you were to include a small contribution sufficient to at
least cover future mailings,  I'd be most inclined to put you on my mailing
list for future updates, packet goodies and the like.

I'll post this set on as many phone BBS sets as possible.  I don't have any
in mind at the moment, so none are listed.  I am not currently on
CompuServ, since our backwater little town does not have a Tymnet node and
I won't pay the buzzards connect charges AND long distance.  If anyone
wants to upload this to Compuserv, feel free to do so.

This program set is copywrited by me!  You may use them, hack them, give
them away, use them in your business, or make a zillion copies to your
hearts' delite.  You may NOT:

1.   Sell this program - This includes charging for copying, other than
     media costs.
2.   Distribute modified versions using the names CHUNK, GLUE or
     CHUNK'N'GLUE.
3.   Change revision numbers and then re-release the programs to the public
     domain.  PLEASE... I'm willing to handle the drudgery of maintaining
     orderly revisions.  Just send your enhancements to me and I'll take it
     from there!

Source code in Microsoft C v4.0 is included (Only a Troll would do
otherwise!), you should feel free to embellish it.  If you come up with
enhancements, bugfixes or the like, please send them to me either by US
SNAIL at the above address or via packet radio @ WD4OQC BBS.  I'll
incorporate the changes into an official update.

XI  OTHER MACHINES.

This code was written for the MicroSoft C V4.0 compiler under MS-DOS.
There is little if any machine- or compiler-specific code in it.  It should
therefore compile and run on most other environments.  If your compiler
and/or operating system does not supply exact file size information to-the-
byte, you will have to write a little function to count bytes in order to
be able to store bytecounts in the chunkfiles.  This will somewhat slow the
system down.

The major requirement is that your compiler be ANSI-draft compatible.
(Before you ask, NO, BDS-C is NOT.)  Most all DOS compilers and some CP/M
compilers such as Aztec should meet this requirement.  if you convert this
program for another compiler/environment, PLEASE send me a copy for
distribution.  PC-format disks preferred, though I can handle most CP/M 5"
formats.

XII   KNOWN TRAPS AND "UNDOCUMENTED BEHAVIOR

1.   With the current header line parser routine, if a tilde, "~" appears
     anywhere BEFORE the header line, the program will report an error.  It
     simply expects to find the header at the first tilde.  So if any of
     the BBS headers have a tilde in them, simply edit them out of the
     chunk files before Glueing them.  This will be fixed in the next
     release.  I got lazy, hi!

2.   If 2 original files have the same file name but with different
     extensions, say BIGFILE.1 and BIGFILE.2, and you want to chunk them
     both, Chunk will overwrite the first series of chunkfiles with the
     second.  This is because both will produce a set of chunkfiles named
     BIGFILE.CHx.  I'm not sure this is a real problem worth the fairly
     extensive coding needed to intelligently trap it, but if you think so,
     let me know.  The easy workaround is to rename the chunkfiles to
     another non-conflicting name before chunking the next one.  The DOS
     command would be "REN BIGFILE.CH* BIGFILE1.CH*".  I will probably make
     the provision to specify the chunkfile names in the next release which
     will positively eliminate this problem.

3.   The GLUE program will terminate with an error message if there is not
     enough RAM available to process the chunkfile in one complete chunk.
     Since I've placed an arbitrary limit of 32k on chunkfile sizes, this
     should not be a problem.  It would be a rare PC indeed that did not
     have 32k of ram available after loading this program.  If this does
     give you a problem, let me know.  I can code the routine to use
     whatever RAM is available.  CP/M users may have a problem, depending
     on how bad your C compiler is.



XIII   COMING ATTRACTIONS

I have a couple of related programs up my sleeve.  The first will be a
fixer program which will read a chunkfile and fix the header to match.
This will permit you to edit chunked textfiles without the necessity to
glue them back together and then rechunk them afterwards.

The second one, primarily of interest to the W0RLI CBBS sysops and those
who use the CBBS code as a personal mailbox, will automatically merge
chunkfiles into the CBBS mail file as messages.  It will have the ability
to be programmed for time so that it will feed a designated number of
chunks per unit time.  And perhaps look at the mail file to determine when
the previous chunks went out and hold off sending more till they move. This
is designed to remove some of the drudgery from the sysop's life.  Sorry
MBL users, but you will not be compatible with this feature.  With no
source, I don't have the time to muddle through Jeff's mailfile format.

I may even write a little program for the users that will squirt the
chunkfiles out to the local bbs per a schedule.  My time constraints will
determine this one.  If anyone is interested in working with me on any of
these,  please contact me by mail or packet or phone and let's coordinate
our efforts.

XIV.   CLOSING NOTE

There are basically 2 schools of thought regarding public domain software.
One school says that you should not release a program until it's perfect.
That you should spend months picking all the nits and eliminating all
possible rough edges.  Never release source and ask for money when you do
finally release only the object file. The other school says that you should
craft a program into reasonably fine order, eliminating all known bugs and
as many rough edges as possible, and then release the program for the early
good of all who can use it.  Make note any known rough edges in the DOC
file, note that there may be other problems, and release the program with
source so others can change things around to suit the specific situation.

I'm a member of this latter school of thought.  I believe that a program
that has a few known bugs but is nonetheless useful is better than promises
of a perfect but non-existent one. Hard to load and execute promises, hi.
As I look over the history of public domain software, I realize that the
truly great programs were handled in just this manner.  This list starts
with the very first commercial grade software, the modem program, XMODEM by
Ward Christensen.  Now Ward probably could have made a handsome chunk of
change selling XMODEM.  Remember, back then there was NO method of sending
data via modem in an error-free fashion.  It could have perhaps taken the
place of CrossTalk as the best seller of modem programs.  Instead, Ward
released the program and the protocol to the public domain.  The rest is
history.  I still use MODEM7 on my CP/M machines and the list of credits to
people who have worked on it would fill a page.






CHUNK'N'GLUE is by no means in the same league with XMODEM, but it does
fill a need and is offered in the same spirit.  Hack it, play with it,
study it, perhaps, criticize it, but please remember that it is free.
Therefore, I cannot support it like a commercial program.  Letters, disks
and packet messages are welcome; phone calls for simple questions are not.
(If you want to collaborate on this or other projects, please DO call. I'm
listed in Information.)  Also remember that this is an early release.
THERE MAY STILL BE UNDISCOVERED BUGS.  I have tested the program
extensively in the PC-DOS 3.1 environment using MicroSoft C v4.0.  I try to
write portable code, but there's no guarantee this program will run on
other than DOS machines.  So, have fun y'all.

                                --- END ---